perm filename DOMAIN.ZZZ[RFC,NET] blob
sn#727537 filedate 1983-10-27 generic text, type T, neo UTF8
RFC ZZZ DRAFT September 1983
Network Working Group P. Mockapetris
Request for Comments: ZZZ DRAFT ISI
DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION
DRAFT of 2 Sep 83 11:05AM
TABLE OF CONTENTS
INTRODUCTION........................................................2
Overview.........................................................3
Implementation components........................................4
NAME SERVER TRANSACTIONS............................................5
Introduction.....................................................5
Query and response transport.....................................6
Overall message format...........................................6
The contents of standard queries and responses...................8
Standard query and response example..............................8
The contents of inverse queries and responses...................10
Inverse query and response example..............................11
The contents of completion queries and responses................11
Completion query and response example...........................12
Header section format...........................................14
Question section format.........................................16
Resource record format..........................................17
Compressed domain name format...................................18
Organization of the Shared database.............................20
SOA record format...............................................22
Query processing................................................24
Inverse query processing........................................26
Completion query processing.....................................26
NAME SERVER MAINTENANCE............................................27
Introduction....................................................27
Conceptual model of maintenance operations......................27
Name server data structures and top level logic.................29
Name server file loading........................................31
Name server remote zone transfer................................34
RESOLVER ALGORITHMS................................................36
Operations......................................................36
DOMAIN SUPPORT FOR MAIL............................................38
Introduction....................................................38
Agent binding...................................................38
Mailbox binding.................................................39
Appendix 1 - Domain Name Syntax Specification......................41
Appendix 2 - Field formats and encodings...........................42
TYPE values.....................................................42
QTYPE values....................................................42
CLASS values....................................................42
QCLASS values...................................................43
Standard resource record formats................................43
Appendix 3 - Internet specific field formats and operations........49
Mockapetris [Page 1]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
REFERENCES and BIBLIOGRAPHY........................................51
Mockapetris [Page 2]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
INTRODUCTION
Overview
The goal of domain names is to provide a mechanism for naming
resources in such a way that the names are usable in different
hosts, networks, protocol families, internets, and administrative
organizations.
From the user's point of view, domain names are useful as
arguments to a local agent, called a resolver, which retrieves
information associated with the domain name. Thus a user might
ask for the host address or mail information associated with a
particular domain name. To enable the user to request a
particular type of information, an appropriate query type is
passed to the resolver with the domain name. To the user, the
domain tree is a single information space.
From the resolver's point of view, the database that makes up the
domain space is distributed among various name servers. Different
parts of the domain space are stored in different name servers,
although a particular data item will usually be stored redundantly
in two or more name servers. The resolver starts with knowledge
of at least one name server. When the resolver processes a user
query it asks a known name server for the information; in return,
the resolver either receives the desired information or a referral
to another name server. Using these referrals, resolvers learn
the identities and contents of other name servers. Resolvers are
responsible for dealing with the distribution of the domain space
and dealing with the effects of name server failure by consulting
redundant databases in other servers.
Name servers manage two kinds of data. The first kind of data
held in sets called zones; each zone is the complete database for
a particular subtree of the domain space. This data is called
authoritative. A name server periodically checks to make sure
that its zones are up to date, and if not obtains a new copy of
updated zones from master files stored locally or in another name
server. The second kind of data is cached data which was acquired
by a local resolver. This data may be incomplete but improves the
performance of the retrieval process when non-local data is
repeatedly accessed. Cached data is eventually discarded by a
timeout mechanism.
This functional structure isolates the problems of user interface,
failure recovery, and distribution in the resolvers and isolates
the database update and refresh problems in the name servers.
Mockapetris [Page 3]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Implementation components
The information flow in a host that supports all aspects of the
domain name system is shown below:
+-------------+ +-------------+
| | user queries | | queries
| User |-------------->| |-------------->
| Program | | Resolver |
| |<--------------| |<--------------
| | user responses| | responses
+-------------+ +-------------+
| A
cache additions | | references
V |
+-------------+
| Shared |
| database |
+-------------+
A |
+-------------+ refreshes | | references
/ /| | V
+-------------+ | +-------------+
| | | | | responses
| Domain | | | Name |-------------->
| data |-------------->| Server |
| files | | | |<--------------
| |/ | | queries
+-------------+ +-------------+
A |
| \------------------>
| maintenance queries
|
\-------------------------
maintenance responses
User programs interact with the domain name space through
resolvers; the format of user queries and user responses is
specific to the host and its operating system. User queries will
typically be operating system calls.
Resolvers answer user queries with information they acquire via
queries to foreign name servers, and may also cache or reference
domain information in the local shared database. Note that the
resolver may have to make several queries to several different
name servers to answer a particular user query, and hence the
resolution of a user query may involve several network accesses
and an arbitrary amount of time. The queries to foreign name
Mockapetris [Page 4]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
servers and the corresponding responses have a standard format
described in this memo, and may be datagrams.
The shared database holds domain space data for the local name
server and resolver. The contents of the shared database will
typically be a mixture of authoritative data maintained by the
periodic refresh operations of the name server and cached data
from previous resolver requests. The structure of the domain data
and the necessity for synchronization between name servers and
resolvers imply the general characteristics of this database, but
the actual format is up to the local implementer. This memo
suggests a multiple tree format.
The primary function of name servers is to process queries from
foreign resolvers and return responses. Name servers have
maintenance processing to load the initial state of the shared
database from local files and foreign name servers. Maintenance
transactions periodically refresh the database.
Less capable hosts will not have all of these features. For
example, an austere host might have only a resolver and a small
cache. In this case most user queries would require accessing a
foreign name server.
This memo divides the implementation discussion into sections:
NAME SERVER TRANSACTIONS, which discusses the formats for name
servers queries and the corresponding responses.
NAME SERVER MAINTENANCE, which discusses strategies,
algorithms, and formats for maintaining the data residing in
name servers.
RESOLVER ALGORITHMS, which discusses the internal structure of
resolvers. This section also discusses data base sharing
between a name server and a resolver on the same host.
DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain
system to support mail transfer.
NAME SERVER TRANSACTIONS
Introduction
The primary purpose of name servers is to receive queries from
resolvers and return responses. The overall model of this service
is that a program (typically a resolver) asks the name server
questions (queries) and gets responses that either answer the
question or refer the questioner to another name server. Other
Mockapetris [Page 5]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
functions related to name server database maintenance use similar
procedures and formats and are discussed in a section later in
this memo.
There are three kinds of queries presently defined:
1. Standard queries that ask for a specified resource attached
to a given domain name.
2. Inverse queries that specify a resource and ask for a domain
name that possesses that resource.
3. Completion queries that specify a partial domain name and a
target domain and ask that the partial domain name be
completed with a domain name close to the target domain.
This memo uses an unqualified reference to queries to refer to
either all queries or standard queries when the context is clear.
Query and response transport
Name servers and resolvers use a single message format for all
communications. The message format consists of a variable-length
octet string which includes binary values.
Messages and message sequences are designed so that queries and
responses can be carried in either datagrams or over reliable
circuits.
To accommodate the datagram style, responses carry the query as
part of the response, and datagram messages are limited to 512
octets. If a datagram message would exceed 512 octets, it is
truncated and a truncation flag is set in its header.
Virtual circuits may also be used for queries. If virtual
circuits are used, the length of a message is not limited.
Because maintenance transactions require reliable service, they
must use virtual circuits.
All messages may use a compression scheme to reduce the space
consumed by repetitive domain names. The use of the compression
scheme is optional for the sender of a message, but all receivers
must be capable of decoding compressed domain names.
Mockapetris [Page 6]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Overall message format
All messages sent by the domain system are divided into 5 sections
(some of which are empty in certain cases) shown below:
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | answering resource records (RRs)
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding pertinent information
+---------------------+
The header section is always present. The header includes fields
that specify which of the remaining sections are present, and also
specify whether the message is a query, inverse query, completion
query, or response.
The question section contains fields that describe a question to a
name server. These fields are a query type (QTYPE), a query class
(QCLASS), and a query domain name (QNAME).
The last three sections have the same format: a possibly empty
list of concatenated resource records (RRs). The answer section
contains RRs that answer the question; the authority section
contains RRs that point toward an authoritative name server; the
additional records section contains RRs which relate to the query,
but are not strictly answers for the question.
The next two sections of this memo illustrate the use of these
message sections through examples; a detailed discussion of data
formats follows the examples.
Mockapetris [Page 7]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
The contents of standard queries and responses
When a name server processes a standard query, it first determines
whether it is an authority for the domain name specified in the
query.
If the name server is an authority, it returns either:
1. the specified resource information
2. an indication that the specified name does not exist
3. an indication that the requested resource information does
not exist
If the name server is not an authority for the specified name, it
returns whatever relevant resource information it has along with
resource records that the requesting resolver can use to locate an
authoritative name server.
Standard query and response example
The overall structure of a query for retrieving information for
Internet mail for domain F.ISI.ARPA is shown below:
+-----------------------------------------+
Header | OPCODE=QUERY, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
The header includes an opcode field that specifies that this
datagram is a query, and an ID field that will be used to
associate replies with the original query. (Some additional
header fields have been omitted for clarity.) The question
section specifies that the type of the query is for mail agent
information, that only ARPA Internet information is to be
considered, and that the domain name of interest is F.ISI.ARPA.
The remaining sections are empty, and would not use any octets in
a real datagram.
Mockapetris [Page 8]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
One possible response to this query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2304 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | ARPA NS IN A.ISI.ARPA |
| ------- |
| ARPA NS IN F.ISI.ARPA |
+-----------------------------------------+
Additional | F.ISI.ARPA A IN 10.2.0.52 |
| ------- |
| A.ISI.ARPA A IN 10.1.0.22 |
+-----------------------------------------+
This type of response would be returned by a name server that was
not an authority for the domain name F.ISI.ARPA. The header field
specifies that the datagram is a response to a query with an ID of
2304. The question section is copied from the question section in
the query datagram.
The answer section is empty because the name server did not have
any information that would answer the query. (Name servers may
happen to have cached information even if they are not
authoritative for the query.)
The best that this name server could do was to pass back
information for the domain ARPA. The authority section specifies
two name servers for the domain ARPA using the Internet family:
A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence
that F.ISI.ARPA is a name server for ARPA as well as the subject
of the query.
In this case, the name server included in the additional records
section the Internet addresses for the two hosts specified in the
authority section. Although name servers are not always able to
include such helpful information, they do so whenever the data is
available.
Given this response, the process that originally sent the query
might resend the query to the name server on A.ISI.ARPA, with a
new ID of 2305.
Mockapetris [Page 9]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
The name server on A.ISI.ARPA might return a response:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=2305 |
+-----------------------------------------+
Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | F.ISI.ARPA MD IN F.ISI.ARPA |
| ------- |
| F.ISI.ARPA MF IN A.ISI.ARPA |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | F.ISI.ARPA A IN 10.2.0.52 |
| ------- |
| A.ISI.ARPA A IN 10.1.0.22 |
+-----------------------------------------+
This query was directed to an authoritative name server, and hence
the response includes an answer but no authority records. In this
case, the answer section specifies that mail for F.ISI.ARPA can
either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The
additional records section specifies the Internet addresses of
these hosts.
The contents of inverse queries and responses
Inverse queries reverse the mappings performed by standard query
operations; while a standard query maps a domain name to a
resource, an inverse query maps a resource to a domain name. For
example, a standard query might bind a domain name to a host
address; the corresponding inverse query binds the host address to
a domain name.
Inverse query mappings are not guaranteed to be unique or complete
because the domain system does not have any internal mechanism for
determining authority from resource records that parallels the
capability for determining authority as a function of domain name.
In general, resolvers will be configured to direct inverse queries
to a name server which is known to have the desired information.
Name servers are not required to support any form of inverse
queries; it is anticipated that most name servers will support
address to domain name conversions, but no other inverse mappings.
If a name server receives an inverse query that it does not
support, it returns an error response with the "Not Implemented"
(NI) bit set in the header. While inverse query support is
optional, all name servers must be at least able to return the
error response.
Mockapetris [Page 10]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
When a name server processes an inverse query, it either returns:
1. zero, one, or multiple domain names for the specified
resource
2. an error code indicating that the name server doesn't
support inverse mapping of the specified resource type.
Inverse query and response example
The overall structure of an inverse query for retrieving the
domain name that corresponds to Internet address 10.2.0.52 is
shown below:
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997 |
+-----------------------------------------+
Question | <empty> |
+-----------------------------------------+
Answer | <anyname> A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
This query asks for a question whose answer is the Internet style
address 10.2.0.52. The response to this query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA |
+-----------------------------------------+
Answer | F.ISI.ARPA A IN 10.2.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
Note that the QTYPE in a response to an inverse query is the same
as the TYPE field in the answer section of the inverse query.
Responses to inverse queries may contain multiple questions when
the inverse is not unique.
Mockapetris [Page 11]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
The contents of completion queries and responses
Completion queries ask a name server to complete a partial domain
name and return a completed domain name that is close to a
specified target domain name.
A completion query includes the partial domain name in QNAME, and
the desired class and type in QCLASS and QTYPE. The target domain
name is specified in an single RR in the additional section of the
query message. Although QNAME uses the standard format for domain
names, it is interpreted as if its last label (the null root
label) was omitted.
When a name server receives a completion query, it first looks for
RRs that begin (on the left) with the same labels as are found in
QNAME (with the root deleted), and which match the QTYPE and
QCLASS. This search is called "whole label" matching. If
multiple hits are found, then the name server selects those
candidates that match the most labels of the target domain name
(on the right). If multiple hits are still found, the name server
returns the shortest domain names.
If the whole label match fails to find any candidates, then the
name server assumes that the rightmost label of QNAME (after root
deletion) is not a complete label, and looks for candidates that
would match if characters were added (on the right) to the
rightmost label of QNAME. If multiple hits are encountered, then
the same winnowing procedure as used in whole label matching is
performed to reduce the answer set.
Implementation of completion query processing is optional in a
name server. However, a name server must return a "Not
Implemented" (NI) error response if it does not support
completion.
Completion query mappings are not guaranteed to be unique or
complete because the domain system does not have any internal
mechanism for determining authority from a partial domain name
that parallels the capability for determining authority as a
function of a complete domain name. In general, resolvers will be
configured to direct completion queries to a name server which is
known to have the desired information.
When a name server processes a completion query, it either
returns:
1. An answer giving zero, one, or more possible completions.
2. an error response with NI set.
Mockapetris [Page 12]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Completion query and response example
Suppose that the completion service was used by a TELNET program
to allow a user to specify a partial domain name for the desired
host. Thus a user might ask to be connected to "B". Assuming
that the query originated from an ISI machine, the query might
look like:
+-----------------------------------------+
Header | OPCODE=CQUERY, ID=409 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ISI.ARPA NULL IN |
+-----------------------------------------+
The partial name in the query is "B", the mappings of interest are
ARPA Internet address records, and the target domain is ISI.ARPA.
Note that NULL is a special type of NULL resource record that is
used as a placeholder and has no significance; NULL RRs obey the
standard format but have no other function.
The response to this completion query might be:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=409 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | B.ISI.ARPA A IN 10.3.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ISI.ARPA NULL IN |
+-----------------------------------------+
This response has completed B to mean B.ISI.ARPA.
Mockapetris [Page 13]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Another query might be:
+-----------------------------------------+
Header | OPCODE=CQUERY, ID=410 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ARPA NULL IN |
+-----------------------------------------+
This query is similar to the previous one, but specifies a target
of ARPA rather than ISI.ARPA. In this case the same name server
might return:.
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=410 |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=B |
+-----------------------------------------+
Answer | B.ISI.ARPA A IN 10.3.0.52 |
| - |
| B.BBN.ARPA A IN 10.0.0.49 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | ARPA NULL IN |
+-----------------------------------------+
This response contains two answers, B.ISI.ARPA and B.BBN.ARPA.
Both were returned because they have equal lengths, and match
equally well.
Mockapetris [Page 14]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Header section format
The header contains the following fields:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Opcode |NE|OC|TC|SF|NI| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID - A 16 bit identifier assigned by the program that
generates any kind of query. This identifier is copied
into all replies and can be used by the requestor to
relate replies to outstanding questions.
OPCODE - A three bit field that specifies the purpose of this
message. The values are:
0 a standard query (QUERY)
1 an inverse query (IQUERY)
2 an completion query (CQUERY)
3-6 reserved for future use
7 a response (RESPONSE)
NE - Name Error - Meaningful only for responses from an
authoritative name server, this bit signifies that the
domain name referenced in the query does not exist.
AA - Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an
authority for the domain name in the corresponding
query.
Mockapetris [Page 15]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
TC - TrunCation - specifies that this message was truncated
due to length greater than 512 characters. This bit is
valid in datagram messages but not in messages sent over
virtual circuits.
SF - Server Failure - specifies that the name server is
unable to process this message because of a temporary
condition at the name server.
NI - Not Implemented - this bit is set in a response from a
name server that does not support the optional service
requested (e.g. inverse query or completion query).
QDCOUNT - an unsigned 16 bit integer specifying the number of
entries in the question section.
ANCOUNT - an unsigned 16 bit integer specifying the number of
resource records in the answer section.
NSCOUNT - an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
ARCOUNT - an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
Question section format
The question section is used in all kinds of queries other than
inverse queries. In responses to inverse queries, this section
may contain multiple entries; for all other responses it contains
a single entry. Each entry has the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE | QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
QNAME - a variable number of octets that specify a domain name.
This field uses the compressed domain name format
described in the next section of this memo. This field
can be used to derive a text string for the domain name.
Mockapetris [Page 16]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Note that this field may be an odd number of octets; no
padding is used.
QTYPE - a single octet code which specifies the type of the
query. The values for this field include all codes
valid for a TYPE field, together with some more general
codes which can match more than one type of RR. For
example, QTYPE might be A and only match type A RRs, or
might be MAILA, which matches MF and MD type RRs. The
values for this field are listed in appendix 2.
QCLASS - a single octet code that specifies the class of the
query. For example, the QCLASS field is IN for the ARPA
Internet, CS for the CSNET, etc. The numerical values
are defined in appendix 2.
Resource record format
The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the
header. Each resource record has the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE | CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | |
+--+--+--+--+--+--+--+--+ |
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME - a compressed domain name to which this resource record
pertains.
TYPE - a single octet containing one of the RR type codes
defined in appendix 2. This field specifies the meaning
of the data in the RDATA field.
Mockapetris [Page 17]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
CLASS - a single octet which specifies the class of the data in
the RDATA field.
TTL - a 16 bit unsigned integer that specifies the time
interval (in seconds) that the resource record may be
cached before it should be discarded. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. For
example, SOA records are always distributed with a zero
TTL to prohibit caching. Zero values can also be used
for extremely volatile data.
RDLENGTH- an unsigned 8 bit integer that specifies the length in
octets of the RDATA field.
RDATA - a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource record.
For example, the if the TYPE is A and the CLASS is IN,
the RDATA field is a 4 octet ARPA Internet address.
Formats for particular resource records are shown in appendicies 2
and 3.
Compressed domain name format
Domain names messages are expressed in terms of a sequence of
labels. Each label is represented as a one octet length field
followed by that number of octets. Since every domain name ends
with the null label of the root, a compressed domain name is
terminated by a length byte of zero. The high order two bits of
the length field must be zero, and the remaining six bits of the
length field limit the label to 63 octets or less.
The overall length of a domain name must be less than 255
characters so that it can fit in the data section of a resource
record (whose length is given in a single octet). It is
recommended that domain names be limited to 200 octets to leave
space for other data fields in a RR.
Although labels can contain any 8 bit values in octets that make
up a label, it is strongly recommended that labels follow the
syntax described in appendix 1 of this memo, which is compatible
with existing host naming conventions. Name servers and resolvers
must compare labels in a case-insensitive manner, i.e. A=a, and
hence all character strings must be ASCII with zero parity.
Non-alphabetic codes must match exactly. Name servers and
resolvers must preserve all 8 bits of domain names they process,
Mockapetris [Page 18]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
because some applications are case sensitive, and because binary
labels may be used in the future.
The intent of these policies is to allow easy use of domain names
composed of printable characters, but to allow experimentation
with binary values in domain names. However, users of binary
names must recognize that the case-insensitive string matching
used by name servers may result in false matches when binary
values are used. It is the responsibility of the users of binary
names to filter out the false matches.
In order to reduce the amount of space used by repetitive domain
names, the sequence of octets that defines a domain name may be
terminated by a pointer to the length octet of a previously
specified label string. The label string that the pointer
specifies is appended to the already specified label string.
Exact duplication of a previous label string can be done with a
single pointer. Multiple levels are allowed.
Pointers can only be used in positions in the message where the
format is not class specific. If this were not the case, a name
server that was handling a RR for another class could make
erroneous copies of RRs. As yet, there are no such cases, but
they may occur in the future.
Pointers are represented as a two octet field in which the high
order 2 bits are ones, and the low order 14 bits specify an offset
from the start of the message. The 01 and 10 values of the high
order bits are reserved for future use and should not be used.
Programs are free to avoid using pointers in datagrams they
generate, although this will reduce datagram capacity. However
all programs are required to understand arriving messages that
contain pointers.
For example, a datagram might need to use the domain names
F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the
other fields of the message, these domain names might be
represented as:
Mockapetris [Page 19]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The domain name for F.ISI.ARPA is shown at offset 20. The domain
name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a
pointer to concatenate a label for FOO to the previously defined
F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a
pointer to the ARPA component of the name F.ISI.ARPA at 20; note
that this reference relies on ARPA being the last label in the
string at 20. The root domain name is defined by a single octet
of zeros at 92; the root domain name has no labels.
Organization of the Shared database
While name server implementations are free to use any internal
data structures they choose, the suggested structure consists of
several separate trees. Each tree has structure corresponding to
the domain name space, with RRs attached to nodes and leaves.
Each zone of authoritative data has a separate tree, and one tree
holds all non-authoritative data. All of the trees corresponding
to zones are managed identically, but the non-authoritative or
cache tree has different management procedures.
Mockapetris [Page 20]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Data stored in the database can be kept in whatever form is
convenient for the name server, so long as it can be transformed
back into the format needed for messages. In particular, the
database will probably use structure in place of expanded domain
names, and will also convert many of the time intervals used in
the domain systems to absolute local times.
Each tree corresponding to a zone has complete information for a
subtree of the domain space. The top node of a zone has a SOA
record that marks the start of the zone. The bottom edge of the
zone is delimited by nodes containing NS records signifying
delegation of authority, or by leaves of the domain tree. When a
name server contains abutting zones, one tree will have a bottom
node containing a NS record, and the other tree will begin with a
tree location containing a SOA record.
Note that there is one special case that requires consideration
when a name server is implemented. Each node that has an SOA will
also have NS records for the name servers for that zone; these NS
records are at the same point in the tree as the SOA, but do not
denote the bottom edge of the zone.
Zones may also overlap a particular part of the name space when
they are of different classes.
Other than the abutting and separate class cases, trees are always
expected to be disjoint. Overlapping zones are regarded as a
non-fatal error. The scheme described in this memo avoids the
overlap issue by maintaining separate trees; other designs must
take the appropriate measures to defend against possible overlap.
Non-authoritative data is maintained in a separate tree. This
tree is unlike the zone trees in that it may have "holes". Each
RR in the cache tree has its own TTL that is separately managed.
The data in this tree is never used if authoritative data is
available from a zone tree; this avoids potential problems due to
cached data that conflicts with authoritative data.
The shared database will also contain data structures to support
the processing of inverse queries and completion queries if the
local system supports these optional features. Although many
schemes are possible, this memo describes a scheme that is based
on tables of pointers that invert the database according to key.
Each kind of retrieval has a separate set of tables, with one
table per zone. When a zone is updated, these tables must also be
updated. The contents of these tables are discussed in the
"Inverse query processing" and "Completion query processing"
sections of this memo.
Mockapetris [Page 21]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
The database includes two locks that are used to control
concurrent access and modification of the database by name server
query processing, name server maintenance operations, and resolver
access:
The first lock ("main lock") controls access to all of the
trees. Multiple concurrent reads are allowed, but write access
can only be acquired by a single process. Read and write
access are mutually exclusive. Resolvers and name server
processes that answer queries acquire this lock in read mode,
and unlock upon completion of the current message. This lock
is acquired in write mode by a name server maintenance process
when it is about to change data in the shared database. The
actual update procedures are described under "NAME SERVER
MAINTENANCE" but are designed to be brief.
The second lock ("cache queue lock") controls access to the
cache queue. This queue is used by a resolver that wishes to
add information to the cache tree. The resolver acquires this
lock, then places the RRs to be cached into the queue. The
name server maintenance procedure periodically acquires this
lock and adds the cache information to the queue. The
rationale for this procedure is that it allows the resolver to
operate with read-only access to the shared database,
centralizes modification procedures, and also allows name
server maintenance operations to be suspicious of update
requests.
This organization solves several difficulties:
When searching the domain space for the answer to a query, a
name server can restrict its search for authoritative data to
that tree that matches the most labels on the right side of the
domain name of interest.
Since updates to a zone must be atomic with respect to
searches, maintenance operations can simply acquire the main
lock, insert a new copy of a particular zone without disturbing
other zones, and then release the storage used by the old copy.
Assuming a central table pointing to valid zone trees, this
operation can be a simple pointer swap.
TTL management of zones can be performed using the SOA record
for the zone. This avoids potential difficulties if individual
RRs in a zone could be timed out separately. This issue is
discussed further in the maintenance section.
Mockapetris [Page 22]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
SOA record format
The SOA records used to mark the start of a zone have the
following format when sent in a message:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE=SOA | CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL=0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | |
+--+--+--+--+--+--+--+--+ |
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The NAME, TYPE, CLASS, TTL and RDLENGTH fields have their standard
RR semantics. Note that TTL is always set to zero to prevent
caching. The remaining fields are standard for all SOA RRs,
regardless of class:
MNAME - The domain name of the name server that was the original
source of data for this zone.
SERIAL - The version number of the of the original copy of the
zone.
REFRESH - The time interval before the zone should be refreshed.
RETRY - The time interval that should elapse before a failed
refresh should be retried.
Mockapetris [Page 23]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
EXPIRE - A 32 bit time value that specifies the upper limit on
the time interval that can elapse before the zone is no
longer authoritative.
MINIMUM - The minimum TTL field that should be exported with any
RR from this zone (other than the SOA itself).
All times are in units of seconds.
Most of these fields are pertinent only for name server
maintenance operations. However, MINIMUM is used in all query
operations that retrieve RRs from a zone. Whenever a RR is sent
in a response to a query, the TTL field is set to the maximum of
the TTL field from the RR and the MINIMUM field in the appropriate
SOA. Thus MINIMUM is a lower bound on the TTL field for all RRs
in a zone. RRs in a zone are never discarded due to timeout
unless the whole zone is deleted. This prevents partial copies of
zones.
Query processing
The following algorithm outlines processing that takes place at a
name server when a query arrives:
1. Search the list of zones to find zones which have the same
class as the QCLASS field in the query and have a top domain
name that matches the right end of the QNAME field. If there
are none, go to step 2. If there are more than one, pick the
zone that has the longest match and go to step 3.
2. Since the zone search failed, the only possible RRs are
contained in the non-authoritative tree. Search the cache tree
for the NS record that has the same class as the QCLASS field
and the largest right end match for domain name. Add the NS
record or records to the authority section of the response. If
the cache tree has RRs that are pertinent to the question
(domain names match, classes agree, not timed-out, and the type
field is relevant to the QTYPE), copy these RRs into the answer
section of the response. The name server may also search the
cache queue. Go to step 4.
3. Since this zone is the best match, the zone in which QNAME
resides is either this zone or a zone to which this zone will
directly or indirectly delegate authority. Search down the
tree looking for a NS RR or the node specified by QNAME.
If the node exists and has no NS record, copy the relevant
RRs to the answer section of the response and go to step 4.
Mockapetris [Page 24]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
If a NS RR is found, either matching a part or all of QNAME,
then QNAME is in a delegated zone outside of this zone. If
so, copy the NS record or records into the authority section
of the response, and search the remainder of the zone for an
A type record corresponding to the NS reference. If the A
record is found, add it to the additional section. Go to
step 2.
If the node is not found and a NS is not found, there is no
such name; set the Name error bit in the response and exit.
4. When this step is reached, the answer and authority sections
are complete. What remains is to complete the additional
section. This procedure is only possible if the name server
knows the data formats implied by the class of records in the
answer and authority sections. Hence this procedure is class
dependent. Appendix 3 discusses this procedure for Internet
class data.
While this algorithm deals with typical queries and databases,
several additions are required that will depend on the database
supported by the name server:
QCLASS=*
Special procedures are required when the QCLASS of the query is
"*". If the database contains several classes of data, the
query processing steps above are performed separately for each
CLASS, and the results are merged into a single response. The
name error bit is not meaningful for a QCLASS=* query. If the
requestor wants this information, it must test each class
independently.
If the database is limited to data of a particular class, this
operation can be performed by simply reseting the authoritative
bit in the response, and performing the query as if QCLASS was
the class used in the database.
* labels in database RRs
Some zones will contain default RRs that use * to match in
cases where the search fails for a particular domain name. If
the database contains these records then a failure must be
retried using * in place of one or more labels of the search
key. The procedure is to replace labels from the left with
"*"s looking for a match until either all labels have been
replaced, or a match is found. Note that these records can
never be the result of caching, so a name server can omit this
processing for zones that don't contain RRs with * in labels,
Mockapetris [Page 25]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
or can omit this processing entirely if * never appears in
local authoritative data.
Inverse query processing
Name servers that support inverse queries can support these
operations through exhaustive searches of their databases, but
this becomes impractical as the size of the database increases.
An alternative approach is to invert the database according to the
search key.
For name servers that support multiple zones and a large amount of
data, the recommended approach is separate inversions for each
zone. When a particular zone is changed during a refresh, only
its inversions need to be redone.
Support for transfer of this type of inversion may be included in
future versions of the domain system, but is not supported in this
version.
Completion query processing
Completion query processing shares many of the same problems in
data structure design as are found in inverse queries, but is
different due to the expected high rate of use of top level labels
(ie., ARPA, CSNET). A name server that wishes to be efficient in
its use of memory may well choose to invert only occurrences of
ARPA, etc. that are below the top level, and use a search for the
rare case that top level labels are used to constrain a
completion.
Mockapetris [Page 26]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
NAME SERVER MAINTENANCE
Introduction
Name servers perform maintenance operations on their databases to
insure that the data they distribute is accurate and timely. The
amount and complexity of the maintenance operations that a name
server must perform are related to the size, change rate, and
complexity of the database that the name server manages.
Maintenance operations are fundamentally different for
authoritative and non-authoritative data. A name server actively
attempts to insure the accuracy and timeliness of authoritative
data by refreshing the data from master copies. Non-authoritative
data is merely purged when its time-to-live expires; the name
server does not attempt to refresh it.
Although the refreshing scheme is fairly simple to implement, it
is somewhat less powerful than schemes used in other distributed
database systems. In particular, an update to the master does not
immediately update copies, and should be viewed as gradually
percolating though the distributed database. This is adequate for
the vast majority of applications. In situations where timliness
is critical, the master name server can prohibit caching of copies
or assign short timeouts to copies.
Conceptual model of maintenance operations
The vast majority of information in the domain system is derived
from master files scattered among hosts that implement name
servers; some name servers will have no master files, other name
servers will have one or more master files. Each master file
contains the master data for a single zone of authority rather
than data for the whole domain name space. The administrator of a
particular zone controls that zone by updating its master file.
Master files and zone copies from remote servers may include RRs
that are outside of the zone of authority when a NS record
delegates authority to a domain name that is a descendant of the
domain name at which authority is delegated. These forward
references are a problem because there is no reasonable method to
guarantee that the A type records for the delegatee are available
unless they can somehow be attached to the NS records.
For example, suppose the ARPA zone delegates authority at
MIT.ARPA, and states that the name server is on AI.MIT.ARPA. If a
resolver gets the NS record but not the A type record for
AI.MIT.ARPA, it might try to ask the MIT name server for the
address of AI.MIT.ARPA.
Mockapetris [Page 27]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
The solution is to allow type A records that are outside of the
zone of authority to be copied with the zone. While these records
won't be found in a search for the A type record itself, they can
be protected by the zone refreshing system, and will be passed
back whenever the name server passes back a referral to the
corresponding NS record. If a query is received for the A record,
the name server will pass back a referral to the name server with
the A record in the additional, rather than answer section.
The only exception to the use of master files is a small amount of
data stored in boot files. Boot file data is used by name servers
to provide enough resource records to allow zones to be imported
from foreign servers (e.g. the address of the server), and to
establish the name and address of root servers. Boot file records
establish the initial contents of the cache tree, and hence can be
overridden by later loads of authoritative data.
The data in a master file first becomes available to users of the
domain name system when it is loaded by the corresponding name
server. By definition, data from a master file is authoritative.
Other name servers which wish to be authoritative for a particular
zone do so by transferring a copy of the zone from the name server
which holds the master copy using a reliable connection. These
copies include parameters which specify the conditions under which
the data in the copy is authoritative. In the most common case,
the conditions specify a refresh interval and policies to be
followed when the refresh operation cannot be performed.
A name server may acquire multiple zones from different name
servers and master files, but the name server must maintain each
zone separately from others and from non-authoritative data.
When the refresh interval for a particular zone copy expires, the
name server holding the copy must consult the name server that
holds the master copy. If the data in the zone has not changed,
the master name server instructs the copy name server to reset the
refresh interval. If the data has changed, the master passes a
new copy of the zone and its associated conditions to the copy
name server. Following either of these transactions, the copy
name server begins a new refresh interval.
Copy name servers must also deal with error conditions under which
they are unable to communicate with the name server that holds the
master copy of a particular zone. The policies that a copy name
server uses are determined by other parameters in the conditions
distributed with every copy. The conditions include a retry
interval and a maximum holding time. When a copy name server is
unable to establish communications with a master or is unable to
Mockapetris [Page 28]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
complete the refresh transaction, it must retry the refresh
operation at the rate specified by the retry interval. This retry
interval will usually be substantially shorter than the refresh
interval. Retries continue until the maximum holding time is
reached. At that time the copy name server must assume that its
copy of the data for the zone in question is no longer
authoritative.
Queries must be processed while maintenance operations are in
progress because a zone transfer can take a long time. However,
to avoid problems caused by access to partial databases, the
maintenance operations create new copies of data rather than
directly modifying the old copies. When the new copy is complete,
the maintenance process locks out queries for a short time using
the main lock, and switches pointers to replace the old data with
the new. After the pointers are swapped, the maintenance process
unlocks the main lock and reclaims the storage used by the old
copy.
Name server data structures and top level logic
The name server must multiplex its attention between multiple
activities. For example, a name server should be able to answer
queries while it is also performing refresh activities for a
particular zone. While it is possible to design a name server
that devotes a separate process to each query and refresh activity
in progress, the model described in this memo is based on the
assumption that there is a single process performing all
maintenance operations, and one or more processes devoted to
handling queries. The model also assumes the existence of shared
memory for several control structures, the domain database, locks,
etc.
The model name server uses the following files and shared data
structures:
1. A configuration file that describes the master and boot
files which the name server should load and the zones that
the name server should attempt to load from foreign name
servers. This file establishes the initial contents of the
status table.
2. Domain data files that contain master and boot data to be
loaded.
3. A status table that is derived from the configuration file.
Each entry in this table describes a source of data. Each
entry has a zone number. The zone number is zero for
Mockapetris [Page 29]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
non-authoritative sources; authoritative sources are
assigned separate non-zero numbers.
4. The shared database that holds the domain data. This
database is assumed to be organized in some sort of tree
structure paralleling the domain name space, with a list of
resource records attached to each node and leaf in the tree.
The elements of the resource record list need not contain
the exact data present in the corresponding output format,
but must contain data sufficient to create the output
format; for example, these records need not contain the
domain name that is associated with the resource because
that name can be derived from the tree structure. Each
resource record also internal data that the name server uses
to organize its data.
5. Inversion data structures that allow the name server to
process inverse queries and completion queries. Although
many structures could be used, the implementation described
in this memo supposes that there is one array for every
inversion that the name server can handle. Each array
contains a list of pointers to resource records such that
the order of the inverted quantities is sorted.
6. The main and cache queue locks
7. The cache queue
The maintenance process begins by loading the status table from
the configuration file. It then periodically checks each entry,
to see if its refresh interval has elapsed. If not, it goes on to
the next entry. If so, it performs different operations depending
on the entry:
If the entry is for zone 0, or the cache tree, the maintenance
process checks to see if additions or deletions are required.
Additions are acquired from the cache queue using the cache
queue lock. Deletions are detected using TTL checks. If any
changes are required, the maintenance process recalculates
inversion data structures and then alters the cache tree under
the protection of the main lock. Whenever the maintenance
process modifies the cache tree, it resets the refresh interval
to the minimum of the contained TTLs and the desired time
interval for cache additions.
If the entry is not zone 0, and the entry refers to a local
file, the maintenance process checks to see if the file has
been modified since its last load. If so the file is reloaded
using the procedures specified under "Name server file
Mockapetris [Page 30]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
loading". The refresh interval is reset to that specified in
the SOA record if the file is a master file.
If the entry is for a remote master file, the maintenance
process checks for a new version using the procedure described
in "Names server remote zone transfer".
Name server file loading
Master files are kept in text form for ease of editing by system
maintainers. These files are not exchanged by name servers; name
servers use the standard message format when transferring zones.
These files have a simple line-oriented format, with one RR per
line. Fields are separated by any combination of blanks and tab
characters. If a line starts with a domain name, that domain name
is used as a location specifier for the RR that follows it. If a
line starts with a blank, it is loaded into the location specified
by the most recent location specifier.
The location specifiers are assumed to be relative to some origin
that is provided by the user of a file unless a location specifier
contains the root label. This provides a convenient shorthand
notation, and can also be used to prevent errors in master files
from propagating into other zones.
The sole exception to this convention is used to include another
file at some point. An include line begins with $INCLUDE,
starting at the first line position, and is followed by a local
file name and an optional offset modifier. The filename follows
the appropriate local conventions. The offset is one or more
labels that are added to the offset in use for the file that
contained the $INCLUDE. If the offset is omitted, the included
file is loaded using the offset of the file that contained the
$INCLUDE command. For example, a file being loaded at offset ARPA
might contain the following lines:
INCLUDE <subsys>isi.data ISI
$INCLUDE <subsys>addresses.data
The first line would be interpreted to direct loading of the file
<subsys>isi.data at offset ISI.ARPA. The second line would be
interpreted as a request to load data at offset ARPA.
Note that $INCLUDE commands do not cause data to be loaded into a
different zone or tree; they are simply ways to allow data for a
given zone to be organized in separate files. For example,
mailbox data might be kept separately from host data using this
mechanism.
Mockapetris [Page 31]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Resource records are entered as a sequence of fields corresponding
to the CLASS, TTL, TYPE and RDATA components. The CLASS field is
optional; if omitted the CLASS defaults to the most recent value
of the CLASS field in a previous RR. The TTL field is also
optional, and is expressed as a decimal number. If omitted TTL
defaults to zero. Because CLASS and TYPE fields don't contain any
common identifiers, and because CLASS and TYPE fields are never
decimal numbers, the parse is always unique.
In general, the fields that make up RDATA are expressed as decimal
numbers or as domain names. Some exceptions exist, and are
documented in the RDATA definitions in appendicies 2 and 3 of this
memo.
Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:
. A free standing dot is used to refer to the current domain
name.
@ A free standing @ is used to denote the current origin.
.. Two free standing dots represent the null domain name of
the root.
\X where X is any character other than a digit (0-9), is used
to quote that character so that its special meaning does
not apply. For example, "\." can be used to place a dot
character in a label.
\DDD where each D is a digit is the octet corresponding to the
decimal number described by DDD. The resulting octet is
assumed to be text and is not checked for special meaning.
( ) Parentheses are used to group data that crosses a line
boundary. In effect, line terminations are not recognized
within parentheses.
; Semicolon is used to start a comment; the remainder of the
line is ignored.
Mockapetris [Page 32]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
For example, a name server for F.ISI.ARPA , serving as an
authority for the ARPA and ISI.ARPA domains, might use a boot file
and two master files. The boot file initializes some
non-authoritative data, and would be loaded without an origin:
.. 9999999 IN NS B.ISI.ARPA
9999999 CS NS UDEL.CSNET
B.ISI.ARPA 9999999 IN A 10.3.0.52
UDEL.CSNET 9999999 CS A 302-555-0000
This file loads non-authoritative data which provides the
identities and addresses of root name servers. The timeouts are
set to high values (9999999) to prevent this data from being
discarded due to timeout.
The first master file loads authoritative data for the ARPA
domain. This file is loaded with an origin of ARPA.
@ IN SOA F.ISI.ARPA (20 ; SERIAL
3600 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS F.ISI.ARPA ; F.ISI.ARPA is a name server for ARPA
NS A.ISI.ARPA ; A.ISI.ARPA is a name server for ARPA
MIT NS AI.MIT.ARPA; delegation to MIT name server
ISI NS F.ISI.ARPA ; delegation to ISI name server
UDEL MD UDEL.ARPA
A 10.0.0.96
NBS MD NBS.ARPA
A 10.0.0.19
DTI MD DTI.ARPA
A 10.0.0.12
AI.MIT A 10.2.0.6
F.ISI A 10.2.0.52
The first group of lines contains the SOA record and its
parameters, and identifies name servers for this zone and for
delegated zones. The second group specifies data for domain names
within this zone. The last group has forward references for name
server address resolution for AI.MIT.ARPA and F.ISI.ARPA. This
data is not technically within the zone, and will only be used for
additional record resolution for NS records used in referrals.
However, this data is protected by the zone timeouts in the SOA,
so it will persist as long as the NS references persist.
Mockapetris [Page 33]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
The second master file defines the ISI.ARPA environment, and is
loaded with an origin of ISI.ARPA:
@ IN SOA F.ISI.ARPA (20 ; SERIAL
7200 ; REFRESH
600 ; RETRY
3600000; EXPIRE
60) ; MINIMUM
NS F.ISI.ARPA ; F.ISI.ARPA is a name server
A A 10.1.0.32
MD A.ISI.ARPA
MF F.ISI.ARPA
B A 10.3.0.52
MD B.ISI.ARPA
MF F.ISI.ARPA
F A 10.2.0.52
MD F.ISI.ARPA
MF A.ISI.ARPA
$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
MOE MB F.ISI.ARPA
LARRY MB A.ISI.ARPA
CURLEY MB B.ISI.ARPA
STOOGES MB B.ISI.ARPA
MG MOE.ISI.ARPA
MG LARRY.ISI.ARPA
MG CURLEY.ISI.ARPA
Name server remote zone transfer
When a name server needs to make an initial copy of a zone or test
to see if a existing zone copy should be refreshed, it begins by
attempting to open a reliable connection to the foreign name
server.
If this connection attempt fails, and this was an initial load
attempt, it schedules a retry and exits. If this was a refresh
operation, the name server tests the status table to see if the
maximum holding time derived from the SOA EXPIRE field has
elapsed. If not, the name server schedules a retry. If the
maximum holding time has expired, the name server invalidates the
zone in the status table, and scans all resource records tagged
with this zone number. For each record it decrements TTL fields
by the length of time since the data was last refreshed. If the
new TTL value is negative, the record is deleted. If the TTL
value is still positive, it moves the RR to the cache tree and
schedules a retry.
Mockapetris [Page 34]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
If the connection attempt succeeds, the name server sends a query
to the foreign name server in which QTYPE=SOA, QCLASS is set
according to the status table information from the configuration
file, and QNAME is set to the domain name of the zone of interest.
The foreign name server will return either a SOA record indicating
that it has the zone or an error. If an error is detected, the
connection is closed, and the failure is treated in the same way
as if the connection attempt failed.
If the SOA record is returned and this was a refresh, rather than
an initial load of the zone, the name server compares the SERIAL
field in the new SOA record with the SERIAL field in the SOA
record of the existing zone copy. If these values match, the zone
has not been updated since the last copy and hence there is no
reason to recopy the zone. In this case the name server resets
the times in the existing SOA record and closes the connection to
complete the operation.
If this is initial load, or the SERIAL fields were different, the
name server requests a copy of the zone by sending the foreign
name server an AXFR query which specifies the zone by its QCLASS
and QNAME fields.
When the foreign name server receives the AXFR request, it sends
each node from the zone to the requestor in a separate message.
It begins with the node that contains the SOA record, walks the
tree in breadth-first order, and completes the transfer by
resending the node containing the SOA record.
The requestor receives these records and builds a new tree. This
tree is not yet in the status table, so its data are not sued to
process queries. The old copy of the zone, if any, may be used to
satisfy request while the transfer is in progress.
When the requestor receives the second copy of the SOA node, it
compares the SERIAL field in the first copy of the SOA against the
SERIAL field in the last copy of the SOA record. If these don't
match, the foreign server updated its zone while the transfer was
in progress. In this case the requestor repeats the AXFR request
to acquire the newer version.
In the AXFR transfer eventually succeeds, the name server closes
the connection and and creates new versions of inversion data
structures for this zone. When this operation is complete, the
name server acquires the main lock in write mode and then replaces
any old copy of the zone and inversion data structures with new
ones. The name server then releases the main lock, and can
reclaim the storage used by the old copy.
Mockapetris [Page 35]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
If an error occurs during the AXFR transfer, the name server can
copy any partial information into its cache tree if it wishes,
although it will not normally due so if the zone transfer was a
refresh rather than an initial load.
RESOLVER ALGORITHMS
Operations
Resolvers have a great deal of latitude in the semantics they
allow in user calls. For example, a resolver might support
different user calls that specify whether the returned information
must be from and authoritative name server or not. Resolvers are
also responsible for enforcement of any local restrictions on
access, etc.
In any case, the resolver will transform the user query into a
number of shared database accesses and queries to remote name
servers. When a user requests a resource associated with a
particular domain name, the resolver will execute the following
steps:
1. The resolver first checks the local shared database, if any,
for the desired information. If found, it checks the
applicable timeout. If the timeout check succeeds, the
information is used to satisfy the user request. If not, the
resolver goes to step 2.
2. In this step, the resolver consults the shared database for the
name server that most closely matches the domain name in the
user query. Multiple redundant name servers may be found. The
resolver goes to step 3.
3. In this step the resolver chooses one of the available name
servers and sends off a query. If the query fails, it tries
another name server. If all fail, and error indication is
returned to the user. If a reply is received the resolver adds
the returned RRs to its database and goes to step 4.
4. In this step, the resolver interprets the reply. If the reply
contains the desired information, the resolver returns the
information to the user. The the reply indicates that the
domain name in the user query doesn't exist, then the resolver
returns an error to the user. If the reply contains a
transient name server failure, the resolver can either wait and
retry the query or go back to step 3 and try a different name
server. If the reply doesn't contain the desired information,
but does contain pointer to a closer name server, the resolver
Mockapetris [Page 36]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
returns to step 2, where the closer name servers will be
queried.
Several modifications to this algorithm are possible. A resolver
may not support a local cache and instead only cache information
during the course of a single user request, discarding it upon
completion. The resolver may also find that a datagram reply was
truncated, and open a virtual circuit so that the complete reply
can be recovered.
Inverse and completion queries must be treated in an
environment-sensitive manner, because the domain system doesn't
provide a method for guaranteeing that it can locate the correct
information. The typical choice will be to configure a resolver
to use a particular set of known name servers for inverse queries.
Mockapetris [Page 37]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
DOMAIN SUPPORT FOR MAIL
Introduction
Mail service is a particularly sensitive issue for users of the
domain system because of the lack of a consistent system and the
need to support continued operation of existing services. This
section discusses an evolutionary approach to adding consistent
domain name support for mail.
The crucial issue is deciding on the types of binding to be
supported. In current systems a mailbox is usually specified as a
two part construct such as X@Y. The left hand side, X, is an
identifier, often a user or account, and Y is a location, often a
host. The problem is that what many want is to divorce Y from a
particular machine and make it a more general field. Thus for
example, we might want to send mail to MOCKAPETRIS@ISI.ARPA rather
than MOCKAPETRIS@F.ISI.ARPA. Another problem is that the left
hand side, X, has been used to contain encoded routes, etc. Thus
it is virtually impossible to impose restrictions on how existing
systems use the left hand side, and difficult to do so for the
right hand side.
The proposed domain support for mail consists of two levels of
support. The first level can bind the Y in an X@Y address to a
host that will accept the mail or direct its forwarding to another
host via a mail protocol, such as SMTP. The second level of
support binds an X@Y combination to a destination, and may also be
used to support binding X@Y to a list members of a mail group.
The first level of support is called "agent" binding, the second
is called "mailbox" binding. It is anticipated that the Internet
system will adopt agent binding as part of the initial
implementation of the domain system, and that mailbox binding will
eventually become the preferred style as organizations convert
their mail systems to the new style. To facilitate this approach,
the domain information for these two binding styles is organized
to allow a requestor to determine which types of support are
available, and the information is kept in two disjoint classes.
Mockapetris [Page 38]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Agent binding
In agent binding, a mail system uses the right side of the mail
name as a domain name, with dots denoting structure. The domain
name is resolved using a MAILA query which uses the MF and MD RRs
to determine the domain name of the appropriate agent. For
example, mail for MOCKAPETRIS@F.ISI.ARPA would result in a MAILA
query for F.ISI.ARPA, which might return a MD RR for F.ISI.ARPA
and a MF RR for A.ISI.ARPA. The mailer would interpret these to
mean that the mail agent on F.ISI.ARPA should be able to accept
the mail, but that A.ISI.ARPA is willing to accept the mail for
probable forwarding.
Note that MD and MF responses are essentially returning defaults
or guesses for the mail agent, based only on the Y part of the X@Y
address. For example, the specified mailbox might actually reside
on B.ISI.ARPA, but this would not be discovered until the mailer
attempted to transfer the mail via SMTP.
Using this system, an organization could implement a system that
divorced mailboxes from actual machines using forwarding.
Mailbox binding
In mailbox binding, the mailer uses the entire mail destination
specification to construct a domain name. The X part of the X@Y
address is used as the most specific part of the domain name, but
is forced to be a single label. The right part of the address is
interpreted using dots to be one or more labels. The resulting
domain name is resolved using a MAILB query, and the returned RRs
may include the types MB, MG, and MR.
A MB or MailBox entry contains a single domain name that specifies
the domain name of a mail agent which will accept the mail. A MG
or MailGroup entry specifies that the mail address specifies a
group, and that one member of the group is specified in the domain
name that is contained in the MG RR. A domain name that specifies
a group will typically have multiple MG records. A MR or
MailRename RR specifies a single domain name that should replace
the mail address.
The domain names in MG and MR resource records are also X@Y
composites; the domain name in a MB RR is a mail agent name and
hence is the domain name of a host. The mailer will need to
perform MAILB binding on MG and MR to determine the proper agent.
Note that it is quite likely that some domain names will have both
MB and MG records. The interpretation of this is that the list is
published and the mailer is free to do the mail "explosion" itself
Mockapetris [Page 39]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
or simply pass the mail to the agent specified in MB and let it do
the explosion.
Given the large amount of information associated with mailboxes
for a specific organization, mailbox binding will usually require
the organization to support its own name server and zone, or
arrange for a name server elsewhere to manage the zone.
Mockapetris [Page 40]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Appendix 1 - Domain Name Syntax Specification
The preferred syntax of domain names is given by the following BNF
rules.
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in domain
names no significance is attached to the case. That is, two names
with the same spelling but different case are to be treated as if
identical.
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
For example, the following strings identify hosts in the ARPA
Internet:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
Mockapetris [Page 41]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Appendix 2 - Field formats and encodings
TYPE values
TYPE fields are used in resource records. Note that these types
are not the same as the QTYPE fields used in queries, although the
functions are often similar.
TYPE value meaning
A 1 a host address
NS 2 an authoritative name server
MD 3 a mail destination
MF 4 a mail forwarder
CNAME 5 the cannonical name for an alias
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name
MG 8 a mail group member
MR 9 a mail rename domain name
NULL 10 a null RR
WKS 11 a well known service description
QTYPE values
QTYPE fields appear in the question part of a query. They include
the values of TYPE with the following additions:
AXFR 252 A request for a transfer of an entire zone of authority
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILA 254 A request for mail agent RRs (MD and MF)
* 255 A request for all records
Mockapetris [Page 42]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
CLASS values
CLASS fields appear in resource records .
CLASS value meaning
IN 1 the ARPA Internet
CS 2 the computer science network (CSNET)
QCLASS values
QCLASS fields appear in the question section of a query. They
include the values of CLASS with the following additions:
* 255 any class
Standard resource record formats
All RRs have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE | CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | |
+--+--+--+--+--+--+--+--+ |
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME - a compressed domain name to which this resource
record pertains.
TYPE - a single octet containing one of the RR type codes
defined in appendix 2. This field specifies the
meaning of the data in the RDATA field.
Mockapetris [Page 43]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
CLASS - a single octet which specifies the class of the data
in the RDATA field.
TTL - a 16 bit signed integer that specifies the time
interval that the resource record may be cached
before the source of the information should again be
consulted. Zero values are interpreted to mean that
the RR can only be used for the transaction in
progress, and should not be cached. For example, SOA
records are always distributed with a zero TTL to
prohibit caching. Zero values can also be used for
extremely volatile data.
RDLENGTH- an unsigned 8 bit integer that specifies the length
in octets of the RDATA field.
RDATA - a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource
record.
The format of the RDATA field is standard for all classes for the
RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, and NULL. These
formats are shown below together with the appropriate additional
section RR processing.
CNAME RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME - A compressed domain name which specifies that the
domain name of the RR is an alias for a cannonical
name specified by CNAME.
CNAME records cause no additional section processing. The
RDATA section of a CNAME line in a master file is a standard
printed domain name.
Mockapetris [Page 44]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
MB RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME - A compressed domain name which specifies a host which
has the specified mailbox.
MB records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MB line in a master file is a standard printed domain
name.
MD RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME - A compressed domain name which specifies a host which
has a mail agent for the domain which should be able
to deliver mail for the domain.
MD records cause additional section processing which looks up
an A type record corresponding to MADNAME. The RDATA section
of a MD line in a master file is a standard printed domain
name.
MF RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MADNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MADNAME - A compressed domain name which specifies a host which
has a mail agent for the domain which will accept
mail for forwarding to the domain.
MF records cause additional section processing which looks up
Mockapetris [Page 45]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
an A type record corresponding to MADNAME. The RDATA section
of a MF line in a master file is a standard printed domain
name.
MG RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MGMNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MGMNAME - A compressed domain name which specifies a mailbox
which is a member of the mail group specified by the
domain name.
MF records cause no additional section processing. The RDATA
section of a MF line in a master file is a standard printed
domain name.
MR RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NEWNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NEWNAME - A compressed domain name which specifies a mailbox
which is the proper rename of the specified mailbox.
MR records cause no additional section processing. The RDATA
section of a MR line in a master file is a standard printed
domain name.
NULL RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ <anything> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Anything at all may be in the RDATA field so long as it is 255
octets or less.
NULL records cause no additional section processing. NULL RRs
are not allowed in master files.
Mockapetris [Page 46]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME - A compressed domain name which specifies a host which
has a name server for the domain.
NS records cause both the usual additional section processing
to locate a type A record, and a special search of the zone in
which they reside. The RDATA section of a NS line in a master
file is a standard printed domain name.
SOA RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
MNAME - The domain name of the name server that was the
original source of data for this zone.
SERIAL - The version number of the of the original copy of the
zone.
REFRESH - The time interval before the zone should be
refreshed.
RETRY - The time interval that should elapse before a failed
refresh should be retried.
Mockapetris [Page 47]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
EXPIRE - A 32 bit time value that specifies the upper limit on
the time interval that can elapse before the zone is
no longer authoritative.
MINIMUM - The minimum TTL field that should be exported with
any RR from this zone (other than the SOA itself).
SOA records cause no additional section processing. The RDATA
section of a SOA line in a master file is a standard printed
domain name for the MNAME fields followed by decimal numbers
for the remaining parameters.
Mockapetris [Page 48]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
Appendix 3 - Internet specific field formats and operations
The Internet supports name server access using TCP [10] on server
port 53 (decimal) as well as datagram access using UDP on UDP port 53
(decimal).
The ARPA Internet uses the following formats for its A and WKS
resource records:
A RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS - A 32 bit ARPA internet address
Hosts that have multiple ARPA Internet addresses will have
multiple A records.
A records cause no additional section processing. The RDATA
section of a A line in a master file is an Internet address
expressed as four decimal numbers separated by dots without any
imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6").
WKS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS - An 32 bit ARPA Internet address
PROTOCOL - An 8 bit IP protocol number
<BIT MAP> - A variable length bit map. The bit map must be a
multiple of 8 bits long.
The WKS record is used to describe the well known services
Mockapetris [Page 49]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
supported by a particular protocol on a particular internet
address. The PROTOCOL field specifies an IP protocol number,
and the bit map has one bit per port of the specified protocol.
The first bit corresponds to port 0, the second to port 1, etc.
If less than 256 bits are present, the remainder are assumed to
be zero. The appropriate values for ports and protocols are
specified in [13].
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to
TCP port 25 (SMTP). If this bit is set, a SMTP server should
be listening on TCP port 25; if zero, SMTP service is not
supported on the specified address.
The anticipated use of WKS RRs is to provide availability
information for servers for TCP and UDP. If a server supports
both TCP and UDP, or has multiple Internet addresses, then
multiple WKS RRs are used.
WKS RRs cause no additional section processing. The RDATA
section of a WKS record consists of a decimal protocol number
followed by mnemonic identifiers which specify bits to be set
to 1.
Mockapetris [Page 50]
RFC ZZZ DRAFT September 1983
Domain Names - Implementation and Specification
REFERENCES and BIBLIOGRAPHY
[1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
Host Table Specification", RFC 810, Network Information Center,
SRI International, March 1982.
[2] J. Postel, "Computer Mail Meeting Notes", RFC 805,
USC/Information Sciences Institute, February 1982.
[3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet
User Applications", RFC 819, Network Information Center, SRI
International, August 1982.
[4] Z. Su, "A Distributed System for Internet Name Service",
RFC 830, Network Information Center, SRI International,
October 1982.
[5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
Information Center, SRI International, March 1982.
[6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
Server", Computer Networks, vol 6, nr 3, July 1982.
[7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
Center, SRI International, December 1977.
[8] J. Postel, "Internet Name Server", IEN 116, USC/Information
Sciences Institute, August 1979.
[9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
RFC 811, Network Information Center, SRI International,
March 1982.
[10] J. Postel, "Transmission Control Protocol", RFC 793,
USC/Information Sciences Institute, September 1981.
[11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1980.
[13] J. Postel, and J. Vernon, "Assigned Numbers", RFC 820,
USC/Information Sciences Institute, January 1983.
[14] P. Mockapetris, "Domain names - Concepts and Facilities,"
RFC XXX, USC/Information Sciences Institute, September 1983.
Mockapetris [Page 51]
Mockapetris [Page 52]